Hi @jordan-powers, I've created a changelog YAML for you.

Would you be able to get jfr / flame graphs from a a run before and after the increase for limit_500? The limit 500 returns all fields. Before all unmapped fields were in one ignored source stored field entry whereas now it is in multiple. This could be a reason in the difference.

After analyzing the flamegraphs, I think the regressions are due to the newly-added runtime fields in elastic/rally-tracks#841.

The regressions are due to a change in the benchmark and are unrelated to the new field visitor.

In the Sep. 8 flamegraphs, we see time spent in the KeywordScriptDocValuesReader and the LongScriptDocValuesReader. These classes are not present in the Sept. 4 flamegraphs.

Flamegraphs:

• baseline (Sep. 4)

  • limit-500_cpu.html
  • chicken-1_cpu.html

• contender (Sep. 8)

  • limit-500_cpu.html
  • chicken-1_cpu.html

Pinging @elastic/es-storage-engine (Team:StorageEngine)

Hi @jordan-powers, I've updated the changelog YAML for you.

Ok, I see, so the addition of runtime fields in the mapping caused these fields also to be retrieved by the limit_500 esql query because it fetches all fields including runtime fields. This makes sense, thanks for checking 👍

It's too much trouble to rename the node feature. If we decide we really need to rename it, it can happen in a follow-up, with guidance from core-infra.